Seunghyeon's lab.

Claude Code로 API 문서 초안 쓰기: 엔드포인트 목록을 주면 요청·응답 예시가 완성되는 법

한눈에 보는 답엔드포인트 목록과 간단한 설명을 Claude Code에 붙여 넣으면, 각 엔드포인트별로 HTTP 메서드, 요청 파라미터, 성공·에러 응답 예시가 포함된 API 문서 초안이 한 번에 생성됩니다. 별도 템플릿 없이도 OpenAPI 스타일의 구조를 따르도록 지시할 수 있고, 생성된 초안을 바탕으로 실제 코드와 맞춰 수정하면 문서 작성 시간을 크게 줄일 수 있습니다.왜 지금 중요한가API를 새로 만들거나 팀 간 협업을 시작할 때, 문서가 없으면 개발자마다 엔드포인트를 다르게 해석합니다. 특히 프론트엔드와 백엔드가 분리된 팀에서는 '어떤 필드가 필수인지', '에러 코드가 무엇인지' 같은 기초 질문이 슬랙 메시지로 쌓입니다. 그렇다고 모든 엔드포인트를 직접 타이핑하기엔 시간이 부족합니다. Claude..

Claude Code로 회의록 구조화하기: 메모를 붙이면 안건·결정·액션아이템이 정리되는 법

한눈에 보는 답회의 메모를 Claude Code 터미널에 붙여넣고 '이 메모에서 안건, 결정, 액션아이템을 각각 표로 뽑아줘'라고 지시하면 됩니다. 파일로 저장된 메모라면 @회의메모.txt처럼 파일을 직접 지정해서 넘길 수 있습니다. Claude Code는 텍스트를 읽고 세 가지 범주로 분류한 뒤 담당자와 마감일 항목까지 포함한 표를 돌려줍니다.왜 지금 중요한가회의가 끝나고 나면 가장 먼저 사라지는 것이 '누가 뭘 하기로 했더라'는 맥락입니다. 슬랙 메모, 노트 앱, 손으로 적은 종이까지 여러 곳에 흩어진 내용을 사람이 직접 분류하면 20분이 훌쩍 지나갑니다. Claude Code는 구조화되지 않은 텍스트를 읽고 논리적 범주를 스스로 판단하기 때문에, 같은 작업을 2분 이내로 줄여줍니다. 특히 반복 회의..

Claude Code로 PR 설명 쓰기: 변경 내용을 주면 리뷰어가 바로 이해하는 본문이 나오는 법

한눈에 보는 답Claude Code에게 git diff나 변경 파일 목록을 붙여 넣고 "PR 본문을 작성해줘"라고 하면, 배경·변경 요약·테스트 방법이 구조화된 Pull Request 설명이 나옵니다. 추가로 PR 형식 템플릿을 함께 넣으면 팀 규칙에 맞는 완성본이 나옵니다.왜 지금 중요한가PR 본문을 대충 쓰면 리뷰어가 맥락을 파악하느라 시간을 씁니다. "로직 수정"한 줄짜리 설명은 리뷰어가 코드 전체를 처음부터 읽어야 한다는 의미입니다.반대로 잘 쓴 PR 본문은 다음 세 가지를 담습니다.왜 바꿨는가 — 문제 상황 또는 요구사항무엇을 바꿨는가 — 핵심 변경 사항 목록어떻게 확인하는가 — 테스트 방법 또는 스크린샷이 세 가지를 매번 직접 쓰는 건 반복 작업입니다. Claude Code는 이 반복을 대신할..

개발이 끝난 뒤 README를 쓰는 건 레고를 다 완성한 뒤 조립 설명서를 새로 만드는 일과 같다. 이미 머릿속에 있는 내용을 다시 꺼내 문장으로 정리하는 과정이 오히려 개발보다 오래 걸린다. Claude Code는 프로젝트 루트의 폴더 구조를 읽는 것만으로 이 작업을 28초 안에 끝낸다. 이 글은 그 과정을 처음부터 따라할 수 있게 풀어낸다.한눈에 보는 답프로젝트 루트에서 명령 한 줄(claude 'README.md 초안 작성해줘')이면 Claude Code가 package.json, Dockerfile, requirements.txt 같은 파일을 스스로 읽고 설치·실행 가이드를 자동 생성한다.초안 품질을 두 배로 올리는 방법은 독자 정의 한 문장뿐이다. "백엔드 경험 없는 기획자 대상"처럼 구체적으로..

버그를 고치는 데 10분, 리포트를 쓰는 데 40분. 이 비율이 낯설지 않다면 이 글이 도움이 된다. Claude Code에 스택 트레이스를 통째로 넘기면, 재현 절차부터 심각도 판단까지 팀이 바로 쓸 수 있는 구조로 나온다.한눈에 보는 답에러 메시지를 "고쳐줘"가 아니라 "분석해줘, 수정은 하지 말고"로 던지면 증상 덮기가 아닌 진짜 원인을 얻는다.스택 트레이스 전문을 붙이면 Claude Code가 파일명·라인 번호·호출 순서를 읽고 원인 가설을 2~3개 제시한다.초안 한 번, 보강 한 줄이면 Severity 판단과 영향 범위까지 붙은 팀 수준 리포트가 완성된다.인용 가능한 핵심 정리검증일: 2026-06-01정의: Claude Code를 활용한 버그 리포트 자동화란, 스택 트레이스와 범위 지정 프롬프..

주석 없는 코드를 처음 열었을 때의 그 막막함, 개발자라면 누구나 안다. 함수 이름만 봐서는 뭘 하는지 알 수 없고, 결국 호출 스택을 세 단계씩 따라가며 코드 전체를 읽게 된다. Claude Code를 쓰면 이 문서화 작업을 명령어 한 줄로 끝낼 수 있다. 이 글은 코드 주석 자동 추가하기 — 함수에 설명을 붙이는 방법을 처음부터 따라할 수 있게 정리한다.1. 왜 지금 이걸 봐야 하나팀 코드베이스에서 가장 많이 듣는 말이 있다. "이 함수 뭐 하는 거예요?" 그리고 그 질문에 대한 대답은 항상 같다. "코드 읽어봐요."주석이 없으면 코드를 읽는 데 시간이 걸리는 게 아니라, 맥락을 재구성하는 데 시간이 걸린다. 변수 이름이 v이고 함수 이름이 process라면 로직 전체를 처음부터 추적해야 한다. 하루..

Claude Code를 쓰기 시작하면서 가장 먼저 맞닥뜨리는 비효율이 있다. 매 세션마다 "이 프로젝트는 Node 기반이고, 테스트는 Vitest로 돌리고, 포트는 3000번입니다"라고 반복 설명하는 일이다. CLAUDE.md는 그 반복을 끊는 파일이다. 한 번 써두면 Claude가 프로젝트를 열 때마다 그 맥락을 기억한 채로 시작한다.1. 왜 지금 이걸 봐야 하나Claude Code는 세션이 끊기면 직전 대화를 기억하지 못한다. 컨텍스트 창이 리셋되기 때문이다. 그래서 신규 세션마다 개발자는 같은 설명을 다시 타이핑하거나, Claude가 엉뚱한 패키지 매니저를 쓰거나 금지된 패턴을 되풀이하는 걸 사후에 수정하는 데 시간을 쓴다.실측해보면 CLAUDE.md 없이 작업할 때 첫 3~5개 턴이 대부분 맥락 ..

Claude Code를 쓰다 보면 갑자기 응답 품질이 떨어지거나, 분명히 말했던 내용을 모른다는 듯 행동하는 순간이 온다. 이 글은 그 원인이 컨텍스트 창 포화라는 걸 모르고 그냥 넘어가던 개발자를 위한 글이다. 증상을 짚고, 실제로 효과 있는 관리법 다섯 가지를 정리했다.1. 왜 지금 이걸 봐야 하나Claude Code는 대화를 "기억"하지 않는다. 매 응답마다 지금까지의 대화 전체를 하나의 긴 텍스트로 묶어서 처음부터 읽는다. 사람처럼 앞 내용을 기억에 저장해두는 구조가 아니다.이 텍스트에는 한계가 있다. Claude Code가 쓰는 모델의 컨텍스트 창은 200K 토큰이다. 한글 기준으로 대략 10만 자 수준이다. 이게 꽉 차면 두 가지 중 하나가 일어난다. 모델이 오래된 내용을 자동으로 잘라내거나,..

Git은 개발자라면 매일 쓰지만, 솔직히 귀찮은 순간이 있다. 커밋 메시지를 뭐라 써야 할지 막막하거나, 브랜치가 어디서 갈라진 건지 헷갈리거나, 충돌 마커가 가득 찬 파일 앞에서 멍해질 때. Claude Code는 이 모든 Git 작업에 직접 개입해 시간을 아껴준다. 이 글은 Git에 익숙하지만 반복 작업이 피곤한 개발자를 위한 실전 가이드다.1. 왜 지금 이걸 봐야 하나Git 자체를 모르는 사람은 없다. 문제는 "잘 쓰는 것"이 생각보다 피곤하다는 점이다.커밋 메시지 하나 제대로 쓰려면 git diff --staged를 열고, 변경 내용을 직접 읽고, 의미 있는 문장으로 요약해야 한다. 브랜치 전략은 혼자 작업하면 그냥 test123 같은 이름이 쌓인다. 충돌이 나면 양쪽 코드를 직접 읽고 어느 쪽 ..

제안서 작성에서 가장 많은 시간을 잡아먹는 건 글솜씨가 아니다. 무엇을 어떤 순서로 써야 할지 결정하는 구조 설계가 진짜 병목이다. Claude Code로 이 병목을 어떻게 없애는지, 실제 흐름을 단계별로 풀어본다.1. 왜 목차부터 먼저 잡아야 하나제안서를 처음부터 순서대로 쓰려고 하면 반드시 막힌다. 1페이지 첫 문장부터 고민하다 보면 형식을 어떻게 잡을지, 분량은 얼마나 할지, 어떤 내용을 앞에 넣을지를 동시에 결정해야 한다. 결국 빈 화면 앞에서 멈추게 된다.목차는 건물의 기둥이다. 기둥이 먼저 서야 벽돌을 어디에 쌓을지 알 수 있다. 기둥 없이 벽돌부터 쌓으면 결국 무너진다.프리랜서, 1인 개발자, 소규모 팀 모두 공통으로 겪는 문제가 있다. 실력은 충분한데 제안서가 늦다. 내용을 모르는 게 아니..